In the current information age, information technology (IT) tools play a significant role in our daily activities. With the proliferation of electronic devices (e.g., desktop computers, notebook computers, tablets, PDAs, smut phones, etc.) in the world, it has been increasingly difficult to keep track of individual devices connected to a network. Such situation is further exacerbated in organizations where a large number of electronic devices are interconnected through the same network to facilitate sharing of data and other information, much of which may be confidential and even possibly proprietary. In order to make the network infrastructure more secure, device management becomes rather complex.
For example, many networks employ a public key infrastructure (PKI) such that in order for a device to be permitted to connect to the network, the device must be authenticated, such as via a public key certification process. More specifically, the PKI is a system for creating, storing and distributing digital certificates which are used to verify that a particular key belongs to a certain user, device or entity. That is, the PKI includes a certificate authority (CA) to create digital certificates which map public keys to users, devices or entities, securely store these certificates in a central repository, and revoke them if necessary.
In order to facilitate and standardize deployment of such certificates in a scalable manner, several protocols have been proposed. However, in order to keep certificates less burnable (i.e. the objective that each certificate is associated with one, and only one, device), many deployment protocols require one-by-one security configuration transaction/deployment. One such protocol is the Simple Certificate Enrollment Policy (SCEP) protocol. It takes much time to construct secure infrastructure for large scale network environment, for initial deployment as well as refreshing security settings for periodic updates or renewals.
An example of a system employing the SCEP protocol is shown in FIG. 1. In such system shown in FIG. 1, a SCEP server 101 and a device 103 are interconnected by network 104. The SCEP server 101 operates as a registration authority to register certificates and associated information for devices (e.g., terminal, printers, other devices, etc.) authorized to be connected in the network environment 104. For example, upon initial registration/certification of a device, the SCEP server 101 communicates, when necessary, with a certificate authority (CA) 102 through firewall 109 for purposes of key pair update, certificate update or renewal, etc. The SCEP server 101 operates in conformance with the SCEP protocol, and as such, each of the devices communicating with the SCEP server 101 must also conform with the SCEP protocol. When a device communicating with the SCEP server 101 conforms with the SCEP protocol, the certification process can be largely automated.
For example, in order to obtain a certificate, a certificate signing request (CSR) in a format specified by the Public-Key Cryptography Standards (PKCS) must be generated and transmitted to the CA. More specifically, the PKCS standard for generating a CSR is PKCS#10. The message under the PKCS#10 requires information which identifies the user, such as version of the PKCS#10 standard supported, the public key previously generated, and various attributes. Such attributes include a distinguished name (DN), organization name, department name (organizational unit), physical address, country, email address, etc. By generating the CSR with the required information, the user has created a certificate. However, such certificate must also be digitally signed by the CA. The communication to sign the certificate must conform to the PKCS#7 standard which assumes that the communicating entities already posses the certificate and requires both entities to use the issuer names (i.e. DN) and issuer assigned certificate serial numbers to identify the certificate in order to verify the signature and decrypt the message. The PKCS#7 standard specifies the syntax of certificates and other encrypted information (i.e. the method by which data is encrypted and digitally signed, as well as the algorithms involved). The certificate is encrypted pursuant to PKCS#7 and may further be encrypted by using the private key previously generated. By performing these encryptions, the certificate has been “signed” to indicate that the user was the one who created the certificate.
However, such approach cannot be employed if the device to be connected does not conform to the SCEP protocol, or the certificate deployment protocol employed for the network environment.